Software applications are typically executed using an operating system of a computer system. As is well known, the WINDOWS-based operating system by Microsoft Corporation of Redmond, Wash. enjoys a large installed base. As a consequence, software makers strive to create software applications that can be executed by the WINDOWS-based operating system so that the software application may enjoy the greatest possible market share.
In most cases, the installation and execution of a software application (such as for example an anti-virus program) may require the loading of a hook DLL (Dynamic Link Library) to replace the existing DLL managed by the WINDOWS-based operating system. In a WINDOWS-based operating system known as the WINDOWS CE operating system, the installation of a given software application may require the loading of a hook DLL to replace an existing target DLL. After the hook DLL is loaded, the hook DLL handles all subsequent calls made by the newly installed application as well as all subsequent calls that are made by existing applications to the now-replaced target DLL. That is, the target DLL that has been replaced does not get called directly by any other application programs. Instead, the target DLL is called only by the replacement hook DLL.
In the WINDOWS CE operating system environment, DLL replacement requires two necessary conditions: 1) that the target DLL be replaced by a replacement DLL during execution, and 2) that the target DLL not be directly called by any application after the hook DLL is loaded except to the extent that calls are made from the hook DLL to the target DLL.
In the WINDOWS CE operating system environment, system DLLs are in ROM (Read-Only Memory). Although ROM DLLs can not be overwritten, a RAM DLL can still replace, practically speaking, the corresponding target DLL in ROM if the RAM DLL shares the same name as the ROM DLL. That is, when loading a DLL, the WINDOWS CE operating system environment only examines the DLL file name and ignores the path string in deciding whether a given DLL has already been loaded. If a DLL has been loaded (whether from RAM or ROM), other DLLs having the same name will not be loaded.
Accordingly, while it is possible to replace an existing ROM DLL with a RAM DLL (by loading the RAM DLL first), this approach creates another problem since DLL replacement also requires that the ROM-based DLL be loadable so that it can be called on by the replacement RAM DLL. This requirement is illustrated in FIG. 1 wherein a hook DLL 102, which is loaded to replace an existing target DLL 104, makes calls to target DLL 104 (the original ROM-based DLL) while all other applications are prohibited from making direct calls to target DLL 104. In other words, after the RAM-based DLL 102 is loaded to facilitate the execution of application 106, application 106 can indirectly make calls to target ROM-based DLL 104 only by making calls to replacement RAM-based DLL 102 first. Likewise, applications 108 and 112 can indirectly make calls to target ROM-based DLL 104 only by making calls to replacement RAM-based DLL 102.
If ROM-based DLL 104 cannot be loaded so that it can be called by replacement RAM-based DLL 102, the second condition for DLL replacement (i.e., that the target DLL not be directly called after the hook DLL is loaded except to the extent that calls are made from the hook DLL to the target DLL) cannot be met. As such, DLL replacement would fail in the WINDOWS CE operating system environment.